Agile principles

J.-M. Bruel
jbruel@gmail.com
version 1.0 2017-01-27

Materials in live…​

This part of the course is inspired by the Agile MOOC from Bertrand Meyer.

The Agile Manifesto

February 2001!

17 authors

Famous ones:

  • Ward Cunningham (Wiki)
  • Kent Beck (XP, JUnit)
  • Ken Schwaber et Jeff Sutherland (Scrum)
  • Alistair Cockburn
  • Martin Fowler
  • …​

The 12 principles

You will find an update version of the principles on Wikipedia:

The 12 principles (updated)

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even in late development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity - the art of maximizing the amount of work not done - is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

Exercise

Find in those "12 principles":

  • Which ones are not principles!
  • Which ones are in fact pratices
  • Which ones are in fact assertions
  • Which one is even wrong!
  • Useless repetitions
  • Where is test mentioned?

12 principles

Elements of solution

The agile values

General ideas that precede the principles.

The agile values (ctd.)

From the manifesto itself:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The agile values (ctd.)

Do not forget the quote that goes with:

while there is value in the items on the right, we value the items on the left more.
http://agilemanifesto.org/

The agile values (ctd.)

From the Agile MOOC:

  • New, reduced role for manager
  • No "Big Upfront" steps
  • Iterative development
  • Limited, negociated scope
  • Focus on quality, achieved through testing

The principles

Several types:

  • Organizational / Managerial
  • Technical

Good NON AGILE principles!

  • Process, procedure and methods
  • Insist on requirements and their quality

Organizational principles

  • Put the customer at the centre
  • Accept change
  • Let the team self-organize
  • Maintain a sustainable pace

More Organizational principles

  • Produce "minimalist" software

    • Develop required features
    • and only those
    • develop only code and tests

YAGNI: You Ain’t Gonna Need It

More Organizational principles: the LEAN view

7 waste of software dev. (M. Poppendieck):

  • Overproduction: extra/unused features
  • Inventory: partially developed work not released
  • Extra processing: unused artifacts
  • Motion: seeking information
  • Defects: escaped defects not caugth by tests
  • Waiting
  • Transportation: handoffs

Technical principles

  • Develop iteratively

    • Frequent working iterations
    • Closed-window rule

  • Treat tests as a key resource

    • All tests must pass (regression)
    • Test first (TDD)

  • Express requirements through scenarios

    • User stories

Roles

  • What happens to the manager?
  • Scrum Roles

    • Product Owner
    • SCRUM Master
    • Team

  • Other roles

Exercise

What are the roles of traditionnal team managers?

Elements of answer

Taken from the Agile MOOC:

  • Define goals
  • Define deadlines
  • Assign tasks
  • Provide interface with higher management
  • Provide interface with Customer
  • Validate requirements
  • Decide wheterg goals have been met
  • Enforce deadlines
  • Coach, mentor
  • Enforce rules and methodology
In Scrum ⇒ no manager!

The (self-organizing) Team

  • Specialists but no specific domain
  • Cross-functional: anyone able to take any task
  • Select the major goals for the iteration
  • Assign tasks
  • Demonstrate results

Product Owner

  • Interface with the Customer
  • Defines the product features
  • Prioritizes features
  • Allows release presentation

Scrum master

  • makes sure that the team properly applies the methodology
  • ensures that the team is functional
  • enables cooperation
  • protect the team
  • helping remove impediments

Practices

  • Plannings & management
  • Meetings & Scrums
  • Development & releases
  • Retrospectives
  • Tests

Plannings & managements

  • Planning poker
  • Scrum of Scrums
  • Storyboards

Meetings

  • Daily meetings

    • Morning
    • "Stand-up" (<15')
    • Everybody participate
    • Commitments/Impediments

  • Planning meetings

    • Sprint Backlog

  • Retrospective meeetings

    • What went right?
    • What could be improved?

  • Review meetings

    • Customers involved

Focus on the Daily meeting

The 3 classical questions:

  • What did you do yesterday?
  • What will you do today?
  • Are there any impediments in your way?

Development

  • Pair programming
  • Mentoring
  • Single code base (vs. branching)
  • Shared code
  • Leave optimization till last
  • Simple design
  • Incremental design
  • Refactoring

Release

  • Early and often
  • Continuous Integration
  • Small, Incremental
  • Weekly cycles

Tests

  • Coding standards
  • Systematic Unit Tests
  • TDD

Artifacts

  • Product Backlog
  • User stories
  • Sprint Backlog
  • Burdown

Product Backlog

  • Property of the Product Owner
  • Maintained throughout the project
  • Open
  • Contains backlog items
  • Includes estimates of business value
  • Includes estimates of dev. effort

User stories

As a

…​

I want to

…​

So that

…​

User stories (cards)

User stories vs. UML Use Cases

User stories (ctd.)

Good features (XP ⇒ INVEST):

  • Independent (from other stories)
  • Negociable
  • Valuable (for the stakeholders)
  • Estimable
  • Small
  • Testable

User stories (ctd.)

Properties:

  • Id
  • Client priority
  • Cost estimation (points, time, …​)
  • Formulation "As a …​"

User stories (ctd.)

Story mapping

Organizing Stories as matrix instead of simple list: Story Mapping.

Must, Should, Could, Wont ⇒ MoSCoW

Story mapping (ctd.)

Another way of presenting: by flow (dependencies between stories)

Storyboard

Velocity

Not progess over time
  • Number of items delivered
  • Burndown chart

Sprint Backlog

Group of User Stories, taken from the Product Backlog and treated in a specific sprint.

Burndown

Classical process

Ready for a quizz?

tuxteacher

Ready for a quizz?

QUESTION

/